@ddobrigk, @aalkin was a bit in a hurry for having central rapidity centrality/multiplicity estimation for pp
I was checking in the AliPhysics implementation and the SPD tracklets estimator is not using any 'build' formula neither for pp nor for PbPb
I implemented the centrality/multiplicity percentile extraction based on SPD tracklets correcting the measured multiplicity with the zvtx distribution profile and according to the SPD tracklets estimator

I was tempted on doing it for SPD clusters at both levels CL0 and CL1 but although for pp there is not 'build' formula, that's not the case for PbPb
I guess the final implementation will need to consider the building formulas in case they depend on run number/period

@victor-gonzalez, SPD tracklets is a special estimator used solely for the estimation of multiplicity matchup in data and MC. It is no meant for analysis. All analysis-level estimators based on central barrel detectors implicitly have a vertex Z correction. Is this what you mean by formula? This topic is more intricate than a git PR discussion, maybe we can take it on mattermost or so

Thanks! Moving to draft in the meanwhile

It is OK to have it in draft
@ddobrigk and I had a chat and what has been done for SPD tracklets is correct
We decided to implement also SPD clusters based centrality/multiplicity estimators, CL0 and CL1, so I will update the PR with them incorporated
I did few tests on PbPb with four different runs and the results values for SPD tracklets and V0M were in reasonable agreement, not the same but not diverging
@aalkin you were more interested in pp. It works also for pp. Perhaps you can make a try. CL0 and CL1 will be there in a couple of hours

@ddobrigk, @aalkin, @jgrosseo having a single SPD Clusters estimator was not appropriate because for PbPB there are two estimators available CL0 and CL1 which are not for pp

Now then, there are the SPD Clusters estimator, which should only be required for pp analysis, and the CL0 and CL1 estimators, which apply only to PbPb analysis

centrality-qa task now tests the five estimators separated into two process functions although the subscription still does not work as expected

@ddobrigk, @aalkin, @jgrosseo, please, have a look at the centrality/multiplicity distributions with the new estimators for pp (SPD Tracklets and SPD Clusters) and PbPb (SPD Tracklets, CL0 and CL1) in https://alice.its.cern.ch/jira/browse/O2-2223

They were obtained with the centrality-qa task with the modifications introduced by this PR

Unfortunately there is an issue which required

• for obtaining the pp results
  • remove from the Join in the processPbPb signature the aod::CentRun2CL0s and aod::CentRun2CL1s tables (deactivating processPbPb seems to not be enough (?))
• for obtaining the PbPb results
  • recover the previous removed tables
  • remove from the Join in the processPP signature the aod::CentRun2SPDClss table (deactivating processPP seems to not be enough (?))

If the above is not done the workflow fails

• when configured and run over pp

Exception caught: Unable to find OutputSpec with label CentRun2CL0s 

• when configured and run over PbPb

Exception caught: Unable to find OutputSpec with label CentRun2SPDClss

For running the workflow

o2-analysis-centrality-table --configuration json://process_test.json | o2-analysis-centrality-qa --configuration json://process_test.json | o2-analysis-multiplicity-table --configuration json://process_test.json | o2-analysis-timestamp --configuration json://process_test.json | o2-analysis-event-selection --configuration json://process_test.json

was used with

{
    "internal-dpl-clock": "",
    "internal-dpl-aod-reader": {
        "time-limit": "0",
        "orbit-offset-enumeration": "0",
        "orbit-multiplier-enumeration": "0",
        "start-value-enumeration": "0",
        "end-value-enumeration": "-1",
        "step-value-enumeration": "1",
        "aod-file": "@filelistPbPb_four.txt"
    },
    "internal-dpl-aod-index-builder": "",
    "internal-dpl-aod-spawner": "",
    "timestamp-task": {
        "verbose": "false",
        "rct-path": "RCT\/RunInformation\/",
        "start-orbit-path": "GRP\/StartOrbit",
        "ccdb-url": "http:\/\/alice-ccdb.cern.ch",
        "isRun2MC": "false"
    },
    "bc-selection-task": {
        "processRun2": "true",
        "processRun3": "false"
    },
    "event-selection-task": {
        "syst": "PbPb",
        "muonSelection": "0",
        "isMC": "false",
        "processRun2": "true",
        "processRun3": "false"
    },
    "multiplicity-table": {
        "processRun2": "true",
        "processRun3": "false"
    },
    "centrality-table": {
        "estV0M": "-1",
        "estRun2SPDtks": "-1",
        "estRun2SPDcls": "-1",
        "estRun2CL0": "-1",
        "estRun2CL1": "-1"
    },
    "centrality-qa": {
        "processPP": "false",
        "processPbPb": "true"
    },
    "internal-dpl-injected-dummy-sink": "",
    "internal-dpl-aod-global-analysis-file-sink": ""
}

as the process_test.json configuration file

This issue is, in my opinion, not related to the PR as such but I guess that until it is fixed probably it is better to keep it as draft
What do you think?

This AliceO2Group/AliceO2#7636 fixes the described issue
I put it ready for review

@ddobrigk The PR implements centrality/multiplicity estimation based on SPD Tracklets, for both pp and PbPb, SPD Clusters, only for pp, CL0, only for PbPb, and CL1, only for PbPb.

The limitation comes from the availability of calibration information.

Compared to Run2 implementation, it does not provide a default calibration in case the selected run does not have calibration available for it in CCDB

I took a look, I think this looks ok! The SPD tracklets are a universal estimator, and the issue with SPD clusters versus CL0 and CL1 is that in Run 2 we ended up having too many different estimators with different names in different collision systems. I think for legacy we keep as is, but it's a reminder that Run 3 also represents a point in which we can try to do better than in the past :-D

In any case, thanks a lot, @victor-gonzalez, for your work!